Activity: Develop Development Case

A development case is developed to be used in a software-development project.

The project's phase plan and organization has a major impact on the process, and vice versa. Therefore, the development of the development case must be coordinated with development of the project plan. See the Artifact: Software Development Plan, section "Project Plan", for more details. For example, if the project decides to use a different set of phases than in the Rational Unified Process, this is something that needs to be captured in the development case.

The project's choice of configuration items also has a major impact on the process, and vice versa. Therefore, the development of the development case must be coordinated with development of the configuration management plan. The configuration items are defined in the configuration management plan. See Artifact: Configuration Management Plan and Concepts: Product Directory Structure. 

Analyze the Project and the Organization

The Artifact: Development-Organization Assessment contains information about the project and the organization. Analyze the factors to decide how they should affect the development case. See the Guideline: Process Discriminants for guidelines on how the main factors influence the choice of process.

Define Scope

Define which core workflows to cover in the development case, by looking at the following aspects of the Development-Organization Assessment:

• Areas where the project members already have a common way of working, where it is not necessary to introduce a new process and tools. For example, if they know how to test, it can be a good idea to not introduce the test workflow of the Rational Unified Process to limit the number of new factors. You can focus on introducing some parts of the Rational Unified Process, to correct problems in their existing process.  See Concepts: Implementing a Process in a Project, section "Improving Process and Tools", for details. 
• Areas (core workflows) where the project must introduce new process and tools, because there is no existing way of working. In some cases there is no existing process and tools to fall back on, and it is necessary to introduce most of the Rational Unified Process, together with supporting tools. See Concepts: Implementing a Process in a Project, section "Change Everything", for details. 
• Problems in the existing process. Focus on improving in areas in which the organization has had problems.
• Which tools they plan to use. If the project has decided to use certain tools, the development case should normally cover the corresponding areas of the Rational Unified Process.
• The project's capacity to change. When looking at the organization's problems there is a tendency to try to fix everything at once, especially since many of these problems occur together. This is usually a fatal trap. Organizations just like individuals can accommodate change but only within a limited range. If they capacity to change is low, you have to go slower, and maybe just introduce one or two core workflows of the Rational Unified Process in the first project.
• Areas where the project's members lack knowledge, or are weak. Let the development case cover these areas. Make sure that it is easy to find the right information in the Rational Unified Process.

We recommend that you implement the Rational Unified Process iteratively, as described in the Concepts: Implementing a Process in a Project. The development case does not have to capture the entire process. Be prepared to not cover all workflows; skip workflows, and delegate process responsibility; see "Delegating Process Responsibility" in Guidelines: Development Case.

Document the result in the section "Scope" in the Development Case. 

Decide How to Perform Each Core Workflow

Once you have decided which core workflows you should introduce, decide the following for each core workflow: 

• How to perform the core workflow. 
• Which parts of the core workflow that should be used. 
• When, during the project's lifecycle, to introduce the core workflows, and their parts. 

To help you decide, there are is a section "Decide How to Perform the Workflow", in each of the following guidelines:

• Guidelines: Important Decisions in Business Modeling
• Guidelines: Important Decisions in Requirements
• Guidelines: Important Decisions in Analysis & Design
• Guidelines: Important Decisions in Implementation
• Guidelines: Important Decisions in Test
• Guidelines: Important Decisions in Deployment
• Guidelines: Important Decisions in Project Management
• Guidelines: Important Decisions in Configuration & Change Management
• Guidelines: Important Decisions in Environment

When you consider to introduce a particular core workflow, or part of a core workflow, take the following into account: 

• Applicability. Is it applicable for the project? Does it really add value to introduce it?  
• Problems and root causes addressed. Does it address any of the perceived problems, and their root causes? 
• Tool support. What tool support is needed?
• Timing. When during the project's lifecycle should it be introduced? See Concepts: Implementing a Process in a Project, for more information.
• Cost of implementing. What is the cost of implementing it in the project? This includes:
  • Cost to train project members. 
  • Cost to install the supporting tools.
  • Cost to develop guidelines and templates.

Tailor Artifacts per Workflow

Tailor the artifacts for each of the core workflows. However, don't do all of the workflows at onceûfocus on the core process workflow that is next to be applied in the project. Perform the following steps:

1. Decide how the artifact (modeling element or document) should be used (see Guidelines: Classifying Artifacts, for more information):
   • Must have.
   • Should have
   • Could have
   • Won't have
2. Decide the review level for each artifact and capture it in the "Review Details". For details see Guidelines: Review Levels. Decide how to review each artifact, i.e. which review procedures to use. 
3. Decide how you should capture the final results of a core workflow. Do you need to store the results on paper? If so, you have to decide on one or several reports that extract the results from the tools, and capture the results on paper. 
4. Decide which tools to use to develop and maintain the artifact.
5. Decide which properties to use, and how to use them. See the Properties table for each artifact, and the section "Tailoring" of each artifact.
6. When relevant, decide which stereotypes to use. For each artifact, see the section "Tailoring."
7. Decide on an outline for the document artifacts. For the respective artifact, see the section "Brief Outline."

In addition to these steps you should also:

• Decide which reports to use. Decide if you need any work reports to extract information from models, and document the information on paper for reviews. These work reports are usually treated as casual since they are temporary and will be discarded as soon as the review is complete. See "Reports" for example of several predefined reports you can use. You may need to tailor the outline.

There are more things to decide for each core workflow. See the guidelines for each core workflow for more details:

• Guidelines: Important Decisions in Business Modeling
• Guidelines: Important Decisions in Requirements
• Guidelines: Important Decisions in Analysis & Design
• Guidelines: Important Decisions in Implementation
• Guidelines: Important Decisions in Test
• Guidelines: Important Decisions in Deployment
• Guidelines: Important Decisions in Environment
• Guidelines: Important Decisions in Project Management
• Guidelines: Important Decisions in Configuration & Change Management

Modify Core Workflows and Activities

Study the modified set of artifacts and the activities that use, create and update these artifacts. Decide whether you should modify or simplify these activities. Note that for each activity input and output artifacts are indicated. Be sure to delete any unnecessary step or activity. Consider the following:

• Introduce new steps, and possibly new activities to reflects the artifacts, reports and documents that you have had to add.
• Examine how the tools used can facilitate, automate, or even suppress some of the steps.
• Introduce into the activities any specific guidelines and rules inherited from the organization's experience. They may be added as guidance points, checkpoints, review items, or left as separate documents that can be referenced.
• Once the activities are known, revisit the workflows that show how activities interplay, removing or adding activities as necessary.
• Whole core workflow can be omitted or created.
• You may have to introduce some additional workers to take care of special activities requiring specific skills.

Describe the changes in the Development Case.

Choose Lifecycle Model

Choose the kind of lifecycle model the project should employ. Refine the Rational Unified Process model and adjust milestones and the milestone evaluation criteria if necessary. You may even decide to omit one or several of the phases, or add or remove milestones. See Phases and Concepts: Iteration for more information and ideas. Document the project's lifecycle model in the section "Overview of the Development Case".

Describe Sample Iteration Plans

Describe at least one sample iteration plan (more likely you will describe several) for each phase. These iteration plans describe how the project will work in different iterations and phases of the project. The purpose of sample iteration plans in the development case is to describe which activities your project will perform, and in which order. As such it can serve as a more detailed iteration plan. The sample iteration plan is important as a way for team members, to understand how the process will be applied.

The description of the sample iteration plan should be brief. Do not include details that belong in the activities, artifacts and guidelines. You can choose to describe the sample iteration plan in terms of activities or workflow details.

These iteration workflows can be captured textually (or graphically), as in the sample iteration plans that are part of the Rational Unified Process (see Phases).

In most cases you should describe at least one sample iteration plan per phase. Describe the sample iteration plans as they are needed; there is no reason to describe how to work during the Transition phase at the beginning of a project. Start by defining how the project will work in the Inception phase.

Identify Stakeholders

The worker Stakeholder represents all possible stakeholders to a project. You need to identify and describe the different types of stakeholders, their needs and responsibilities. Examples of different stakeholders are customer representative, user representative, investor, production manager, and buyer.

Describe the different stakeholders and their needs in the development case, in the section "Workers".

Map Workers to Job Positions

In some development organizations there are job positions defined. If these job positions are commonly used and have a wide acceptance within the organization, it may be worth doing a mapping between the workers in the Rational Unified Process, and the job positions in the organization. Mapping job positions to workers can make it easier to make people in the organization understand how to employ the Rational Unified Process. The mapping can also help people understand that workers are not job positions, which is a common misconception. Document this mapping in the development case, section "Workers".

Document the Development Case

Describe the development case. We recommend that you describe the development case on one or several web pages, with hyperlinks to the Rational Unified Process online, and to other guidelines. This is explained in the section "Representing a Development Case Online" in Guideline: Development Case. Use the Example: Development Case as a starting point. See also, Tool Mentor: Creating a Development Case, Tool Mentor: Adding External Links to RUP, and Tool Mentor: Authoring Web Pages.

Maintain the Development Case

Many of the decisions should be made before the project starts. After each iteration in the software-development project you should evaluate the process, and reconsider the decisions you have made. If a new version of the Rational Unified Process is released you need to update the development case. This is explained in the Tool Mentor: Upgrading to a new RUP.

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Rational Unified Process